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EURO PAYM ENT ROUTING AND INTRA-DAY FLOW C ONTROL 

S YSTEM AND METHW 

FIELD OF THE INVENTION 

The present inventioii generally relates to systems and 
methods for the routing of payment transactions between financial 
institutions and more particularly to a system and method for routing and 
controlling the flow of Euro payments through a plurality of clearing 
chaxmels. 

BACKGROUND OF THE INVENTION 

Effective Januaiy 1, 1999, the Euro was established as an 
official currency of many of the countries of the European Economic 
Union (EU). Currently, the members of the EU which have converted to 
the Euro are Germany, France^ Spain, Belgium, Ireland, Italy, Luxembourg, 
The Netherlands, Austria, Portugal and Finland, The previous currencies 
of these countries will continue to be available for a transition period. 
They will be denominations of the Euro at fixed conversion rates. The 
Euro will have broad effects tiiroughout Europe even though eveiy 
European is not participating from the beginning. At the end of 2001 the 
previous currencies will cease to exist for electronic and account balance 
piuposes. In the year 2002, the eleven European Union member states 
listed above will officially replace their previous currency notes and coins 
by Euro notes and coins. 

For each national currency (e.g., French Francs) the 
conversion rate to the Euro has been set and is fixed (will not fluctuate). 
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Foreign exchange operations in Euros have now beguiL All new public 
debt issues in each of the EU countries will be in Euros and many 
outstanding ones will be re^nominated. National bank notes and coins 
will not yet be replaced, but banking is possible in both Euro and the 
national currency. 

By January 1, 2002, Euro notes and coins will gradually 
replace notes and coins in &e national currencies. The national currencies 
must be withdrawn by July 1, 2002 at the latest. For companies outside of 
the financial sector, the main costs in converting to the Euro will be 
adapting information systems and, quite possibly reorganizing structures 
and procedures. The costs in the financial sector will be higher. Banks 
have had to be ready to operate in the Euro from January 1, 1999, in order 
to be able to handle payments by companies and individuals and to 
cooperate vnUi the European Central Bank, ECB, in the implementation of 
monetary policy. This has required banks to adapt their computer systems 
to handle die new currency, to reorganize their operations in financial 
markets, to train stafT and to develop new product and services for 
companies and individuals. 

While no one is compelled to use the Euro before January 1, 
2002, banks have had to prepare for the possibilities that some, many, or aU 
of their customers might wish to do so. For those customers wanting Euro 
services before the year 2002, banks may offer Euro accounts. During the 
transitional period (January 1, 1999 through December 3 1, 2001), it would 
be possible for customers to keep their accounts in national currency and 
the banks will take care of receiving and making any Euro payments on 
these accounts at the fixed conversion rate. 

The Trans-European Automated Real-Time Gross settlement 
Express Transfer (TARGET) system is the electronic payment system 
which is a crucial instrument for the European Central Bank's conduct of 
monetary policy. It is one mechanism which enables the cross boarder 
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transfer of funds between banks in real time and allows payments to be 
made through the Euro zone at low cost with high security and very short 
processing times* TARGET also helps the development of sound and 
efficient payment mechanisms in the single market. 

Together widi the fifteen National Central Banks (NCBs) of 
the member countries, the ECB is part of the European System of Central 
Banks (ESCB) whose primary objective is maintaining price stability. The 
ESCB's basic tasks includes defining and implementing monetary policy 
for the Euro, conducting foreign exchange operation and holding and 
managing the official foreign reserves of die membered states. The ECB 
also promotes the smooth operation of payment systems and contributes to 
the work of the relevant national audiorities and supervising credit 
institutions and stability of the financial system. 

Prior to flxe introduction to the Euro, there were 
approximately fourteen different systems for same day value clearing of 
payments in die 1 1 countries. Same day value clearing refers to the system 
and processes by which high value transactions are typically executed. 
With the introduction of die Euro, there are approximately nineteen same 
day clearing systems, but the clearing process now takes place in Euros, 
and not in any national currency. Furthermore, prior to the introduction of 
the Euro, clearing transactions in a particular currency were limited to same 
day clearing systems in diat currency and diese typically only exist in die 
country of the currency. For example, if two German banks were 
processing a payment between two customers in French Francs, the 
transaction had to have been cleared through the French clearing system. 
Now, this payment can be made dirough any of the 19 clearing systems as 
all of diem are required to conduct transactions in Euros. 

The nineteen different clearing systems are constituted by 
fifteen Real Time Gross Setflement Systems (RTGS) and four non RTGS 
systems. 
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Figure 1 illustrates a cleaiing process prior to the introduction 
of the Euro. The example depicted in Figure 1 is a clearance between two 
German clearers 10, 15. As illustrated in this Figure, there were only two 
clearing systems EAF-2 20 and ELS 25 by which these two German 
clearers could process high value payments. 

Upon the introduction of ±b Euro, as depicted in Figure 2, a 
clearing between two Euro clearers 30, 35 can now take place through 
approximately 19 different same day clearing systems. These systems 
include the four non RTGS systems 40, and 15 RTGS systems 45. By 
using an RTGS 45 a Euro clearer 30, 35 can route a payment through the 
TARGET system 50 to reach a destination Euro clearer 30, 35. 
Furthermore, as illustrated in Figure 2, a Euro clearer 30, 35 can use a 
correspondent financial institution 55 to direcdy clear a payment or use the 
coirespondent 55 to clear a payment through an RTGS or non RTGS 
system 60 to which die Euro clearer is not a member. A clearer 30, 35 will 
be a member of one or more of the RTGS or non RTGS systems. 

SUMMARY OF THE INVENTION 

The present invention is a system and method of routing Euro 
payments through one of the plurality of clearing channels. The method of 
the present invention is accomplished by two mam processes, a routing 
process, and a flow control process. The routing process decides which 
clearing channel to use based on a number of factors such as the 
availability of the channel, customer instructions for routing, the clearing 
system memberships of tiie destination bank, agreements with the 
destination bank, priorities, and the type of payment. The flow control 
process monitors the balance for a clearing member within a selected 
channel, and the balance of the channel as a whole. Depending on whetiier 
the balances exceed predetermined limits, the flow control process will 
either hold a routed payment or release it down the channel. The system 
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and method will allow customers to request specific Euro clearing 
mechanisms to be used for the Euro payment In the preferred 
embodiment, all clearing transactions for a financial institution will be 
processed by a central legal hub. This is likely to require cross border 
membership of clearing systems. The routing and flow control processes 
are executed at this central hub. In an alternative embodiment, the routing 
clearing system membershq>s/access can be accomplished on a branch by 
branch basis, but wi& central control monitoring the routing and flow 
control. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For the purposes of illustrating the present invention, there is 
shown in the drawings a form which is presently preferred, it being 
understood however, that the invention is not limited to the precise form 
shown by the drawing in which: 

Figure 1 illustrates a prior art method of clearing a payment 

Figure 2 depicts the prior art channels of clearance after the 
introduction of the Euro; 

Figure 3 illustrates an overview of the system of die present 

invention. 

Figure 4 illustrates a preferred embodiment of the system of 
the present invention. 

Figure 5 is a flow chart of the preprocessing, routing and 
flow control processing at a hub location. 

Figure 6 shows the initial flow chart of the routing process. 

Figure 7 is a flow chart of the routing process when no route 
has been specified. 

Figure 8 depicts die decision process for selecting a channel 
where multiple are available. 
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Figure 9 is a table containing details of the members of the 

clearing systems. 

Figure 10 illustrates a table containing die details of all the 
channels through which the hub can directly or mdirectly process a 
payment 

piTSrilTPTION OF THE INVENTION 

An overview of a preferred embodiment of the present 
invention is illustrated in Figure 3. Element 100 represents Ae global 
operations of a financial institution such as a bank. Elements 105-1 15 
represent the branches or subsidiaries of the bank distributed throughout 
the world. Element 120 represents a central legal entity, a hub, of the bank. 
In a preferred embodiment of the invention, hub 120 is a branch or 

subsidiary of die bank itself. 

Elements 125-150 represent six specific clearing channels to 
which the hub 120 is connected. Element 45 generically represents any 
RTGS clearing system while element 40 generically represents the MLNS 
systems. As in the prior art depicted in Figure 2, the hub 120 is also 
connected to correspondent financial institutions 55. Furthermore, each of 
the RTGSs 45, 125, 130 and 135 are illustrated as being connected to the 
TARGET system 50. As previously explamed, through the TARGET 
system 50 any of the RTGSs are able to clear a payment through another 
RTGS. Other RTGS 45 and other non RTGS 40 clearing systems are 
important because they illustrate the flexibility of this invention. It is easy 
to add or drop clearing systems as appropriate with negUgible impact on 
customers. This flexibility ux usmg alternative channels is also very 
valuable in contingency situations. 

Operationally, all of the same day value payments to be 
cleared firom the financial institution 100 are forwarded from tiie various 
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branches 105-1 15 to the central hub location 120. As the single hub 
location 120 receives all of the payments to be cleared, it has die ability to 
manage the clearance process for the entire financial institution 100. As 
will be more fully described below, this management function includes two 
primary components relating directly to the clearing channels, one for 
determining the routing of the payment through an appropriate channel, and 
one for controlling the flow of all of the financial institution's payments 
among all of the chaimels. Figure 4 schematically illustrates this payment 
routing and flow control portion 170 of the hub. Further illustrated in 
Figure 4 are the institutional and corporate customers 160 of the various 
branches 105-115 and hub branch 120. 

The method executed by the hub 120 in processing payments 
is illustrated in Figure 5. Step 200 in Fig. 5 processes incoming electronic 
messages (payment instructions) received by the hub 120. Such messages 
are transferred between the branches 105-1 15 and the hub 120 and between 
the institutional and corporate customers 160 and the hub 120. These 
messages can take many forms. Alternatively, payment instructions may be 
handled manually in which they are entered for processing via Manual 
Payment Input 215, With respect to payments, the transaction normally 
contains all of tiie relevant information required to process the payment 
including at least an identification of the payor, tiie payee and the amount. 
Sometimes it is necessary to refer back to the transaction originator. 

When one of the customers of the hub 120 (e.g., branches 
105-115 or institutional or corporate customers 160) sends a payment 
instruction to the hub 120, the instruction may, but does not have to include 
routing instructions. For example, the customer of the hub might specify 
fliat the payment should be cleared through either RTGS or non RTGS 
without specifying the specific system to which routing can be made. 

The customer of the hub 120 can signify RTGS or non RTGS 
and additionally specify the specific RTGS non RTGS charmel for use in 
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the routing. If a specific channel is identified, the hub 120 may or may not 
be a member of tiiat specific channel. If die hub 120 is a member of that 
specific channel, the routing process described below will attempt to satisfy 
that specific request If the hub 120 is not a member of tiie specific 
requested channel, the straight through processmg 220 will set the payment 
type to CLG which mdicates that the router is fi-ee to decide upon the route 
which the payment will take. Similarly, if the customer of die hub 120 
does not specify any routing preferences, the payment type will be set to 
CLG. 

The straight through processing 220 also ensures that 
sufficient details are contained in the payment instruction fi-om the 
customer of die hub such that once the transaction gets to the payment 
routing (described below) die router will have sufficient details to choose 
any of the available clearing channels widiout having to send the 
transaction for manual inspection and repau-. The validation process in 
step 220 ensures that sufficient details are available to process the payment 
transaction througih the preferred payment channel for the transaction. If 
the payment is for same day value, dien any closed channels (past cut ofiO 
are ignored when determining the preferred channel. If die payment can be 
made through only one clearing system then step 220 will ensure that 
sufficient details are present to process the payment transaction duough 
diat clearing systeuL If the payment can be made through many clearing 
systems, die straight through processing step 220 will ensure diat sufficient 
details exist to process the payment transaction dirough only die preferred 

clearing system. 

Although the above has described the initial message 
processing 200 for messages sent firom die branches 105-115 of die 
financial institution 100, similar rules apply if the payment mstmction is 
coming direcdy from the institutional or corporate customers 160 of the 
hub 120 itself as depicted in Figure 4. This initial message and vaUdation 
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process 200 and the manual equivalent 215 are preferably also performed 
at each of the branches 105-1 15 as it receives payment instructions from its 
customers 160. 

Initial message processing 200 also processes incoming 
messages from the clearing systems which contain credits for customers 
160 of the financial institution 100 or for the financial institution 100 itself. 
When a credit comes through a channel, the credit must be processed in 
order to update the relevant control balances described below. To do this, 
tiie credit message identifies the clearing channel from which the credit 
came and the bank which sent die payment into the clearing channel. For 
credits received cross-border via TARGET the bank who sent the payment 
into the clearing channel will be the National Central Bank for ^t 
channel. The flow control process of the present invention described 
below is not interested in the particxilar customer 160 of the financial 
institution 100 for which the credit is destined (or for itself), flow control is 
only interested in the fact that a credit came in from a particular clearing 
channel. This is because flow control is only interested in maintaining 
balances on all of the channels and pay-banks and in keeping track of when 
a particular channel or pay-bank reaches its limit. The ftirther processing 
of credits do not form part of the present invention and are not discussed 
herein. 

In step 210, the initial message processing has identified 
outgoing payments received from customers of die hub 120. 

Payment instructions may be received via automated (steps 
200-210) or manual (step 215) means. Certain automated instructions may 
be of such a format that they are printed and processed as manual 
instructions. With transactions which are processed automatically, there 
are sophisticated processes to try to process these transactions without any 
manual intervention whatsoever. This is referred to as Straight Through 
Processing (STP) and the primary processing is in boxes 200, 210 and 220. 
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Where such a transaction cannot be processed straight through, it will go to 
payment repair 225 where an operator will amend the transaction such that 
it can continue processing. Only &ose details which are invalid or missing 
need be manually entered as all other details from the electronic processing 
are available. 

In extreme situations^ it may be necessary to remove a 
transaction from &e electronic processing and re-enter it as a manual 
instruction via Manual Payment Input 215. Manual Payment Input 215 
perfomis an equivalent role to initial message processing 200 and the two 
subsequent stages 210 and 212, but on manual transactions. Manual 
transactions may originate as manual instructions, or from automated 
instructions which are printed on receipt, or from automated instractions 
which are removed from Payment Repair 225, or from certain otiiier 
exception situations. 

Transactions entered via manual payment input 215 are 
subject to Verification 230 of critical data by a second operator. Similarly, 
transactions going though payment repair 225 are also subject to 
Verification 230. If an error is identified at Verification 230, the 
transaction is returned to an earlier stage for correction. 

Under certain conditions, automated instructions may be sent 
direct from Straight Through Processing 220 to Verification 230. In rare 
instances, transactions at subsequent stages may be returned to Payment 
Repair 225. 

After Straight Through Processing 220 or verification 230, 
transactions are fiilly validated. In Forward Value 235, transactions may 
be held in a queue awaiting value date. When flie value date occurs, the 
transactions are released from the forward queue. Transactions are subject 
to Risk Control 245 which ensures that the outgoing payments for a 
particular customer do not exceed tiie receipts by more than a defined limit. 
It is desirable to do this process as late as possible to keep the limits to the 
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miTiimnm Full automation of all subsequent stages of processing, e,g. in 
payment routing and flow control, is essential to minimize tiie limits, and 
therefore the risk which is taken by the financial institution. 

On entering die Router 250, a brief variable delay period is 
applied in case the last manual operation proved to be incorrect. This 
allows the operator to retrieve this transaction. Once this delay period has 
e?q>ired, the transaction becomes irrevocable, unless identified as an 
exception at one of the subsequent automated states. On becoming 
irrevocable, tiie transaction status is updated to (transaction) inactive. 

Element 250 is the Payment Router of the present invention. 
Payment router 250 shall be discussed below in more detail, but in general 
the Payment Router 250 decides, based on a series of rules, how a payment 
should be routed through the various channels 280. Chaimels 280 
gcnerically describe the various RTGS and non RTGS channels previously 
described. Once the appropriate channel for transmission of the payment 
has been determined by Payment Router 250, tiie Payment Router 250 
passes the payment transaction onto the flow control processes 255. 

The first flow control method, bi-lateral limit validation 260, 
checks the proposed payment against die balance cuirentiy maintained by 
the hub 120 for the clearing member (the destination pay-bank on an 
individual channel basis). This will only q)ply where the transaction is 
being routed down a channel to which both the hub 120 and the destmation 
pay bank are directiy connected. All cross border transactions via 
TARGET will be accumulated against tiie National Central Bank which 

operates tiie system. 

The flow control processing monitors the bi-lateral limits 
within the clearing systems. It maintains the total number and amounts of 
payment set to each destination clearer on a daily basis. If a proposed 
payment would put the totals over the limit which has been set for that 
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destination clearer, then the flow control process puts a hold on the 
payment and will not let it be transferred out of the hub 120. 

A second process 262 performed in tiie Flow Control module 
255 looks at the ma y^^^Tn amount for an individual payment through each 
channel 280. Transactions which are above this maximum level require 
manual action. 

The third process 265 performed in die flow control method 
255 looks at die balance for the selected channel as a whole. In steps 260- 
265, it is determined whether or not die proposed payment transaction 
exceeds set limits. If the proposed payment would exceed one of diese 
predetermined limits in any of theses steps 260-265, die determination of 
the fate of the proposed payment may be determined in an on-line flow 
control process 270. Altematively there are automated re-try processes 
widiin die bi-lateral 260 and overall checks 265 which are invoked 
periodically during the day to take into account each new credit received 
for die relevant channel 280. 

In die on-line flow control process 270, an operator manually 
reviews the transaction and die current circumstances which caused the 
transaction to exceed die predetermined limits. The operator may have 
additional knowledge by which he or she may determine that a payment 
may be passed on to a particular channel even though its clearing wiU 
exceed the predetermined limits. For example, the operator might have 
knowledge diat a particular credit has not yet been posted to the channel 
balance and that die processing of the proposed payment transaction will 
not be denied by the channel because of excess debits. At diis stage, in 
rare instances, the operator may need to return the payment to Payment 
Repair 225. 

The on-line flow control function 270 also provides for 
inquiring on and controlling payments held at the various stages of the flow 
control checks 260, 265. The on-line flow control process 270 is manually 
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Operated by the operators at the hub 120. Using this on-line system 270 the 
operators are able to select one or more of the clearing queues in order to 
display all of the held payments. Additionally, the operators can manually 
release any of the queued payments down the specified channel 280 if 
required. Furthermore, the operators can manually put a payment back into 
the Payment Router 250 so a different channel 280 can be selected Re- 
routing back to the Routing module 250 or releasing of a payment from the 
hold queue will cause the bi-lateral and channel totals to be automatically 
updated as appropriate. 

The flow control limits for each of the channels and the 
clearing member banks are stored in a table. These limits are keyed both 
with respect to the clearing member bank to which payment instructions are 
sent, and by the clearing channel. The table contains the agreed upon 
balance limits, the current balance, the number of payments held due to the 
limit checks, and the maximum value of mdividual payments allowed. 
These limits can be manually updated in a rapid fashion if a contingency 

situation arises. 

A function exists which allows the manual adjustment of the 
flow control balance for a clearing channel. This is important to take into 
account any non-clearing related movements across the external clearing 
accounts, for example liquidity movements or start of day RTGS balances. 

The flow control processing has a number of generic defaults 
which ^ply in new situations where limits have not previously been set by 
tiie operators. For example where a new bank joins a clearing, if an 
operator has not previously defined a limit for that bank then some default 
processing will apply to control payments for that bank with a limit forcing 
all payments to be held. 

Once the proposed payment has passed the flow control 
processing 255, it is passed on to the Product Generation module 275. In 
Product Generation 275, the actual message which is transmitted to the 
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chaimels 280 for clearing is generated The format of the messages which 
are generated, will differ depending on which channel 280 is used. Upon 
reaching a defined stage of processing, the channel 280 will return an 
acknowledgment 285 which is used to update the hub's 120 records as 
appropriate. Other products may be generated in Product Generation 275 
such as advices to various parties to the transaction. 

A contingency function is provided to capture payments that 
have either been rejected at the clearing bank or encountered in an error at 
some stage of the payment flow out to the clearing bank. If such is the 
case, flxe rejected or errored payments can be manually set back to payment 
repair (step 225) or back to the Payment Router 250 (see step 300 in Fig. 

6). 

Figures 6-8 illustrate the processing of die Payment Router 
250 of the presentinvention. The processing starts at step 300 with an 
initialization process 305 in which technical preparatoiy woik is 
performed. 

In step 3 10, &e record for the proposed transaction is read. 
As previously described, flie message from fiie customers of the hub 120 
will contain at least an identification of the payor, payee and the amount of 
the payment Additionally, the transaction record may contain an 
identification of a clearing chaimel which is preferred by flie customer 160. 
If the customer does not identify a preferred channel of clearance, this field 
will contain the payment type CLG. In step 325, it is determined whether 
or not a clearing channel has yet been identified. As previously described, 
this channel can be identified by the customer, or alternatively can be 
manually entered by the operators of the hub 120. If the payment type is 
set to CLG, the router is free to automatically determine the appropriate 
chaimel for routiag as illustrated in Figures 7 and 8. During this 
subsequent routing decision process, the payment type will change to EAF, 
EBA, etc, once the appropriate route has been decided. 
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If the routing has akeady been determined (payment type is 
not CLG), the process moves to step 330. Examples of payments for which 
routing has akeady been decided (i.e., the specific channel has been 
defined) are: liquidity payments; payments for which the customer 160 has 
specified the exact clearing channel to be used; or payments for which the 
operators of Ae hub have manually input the channel. Although these 
types of payments do not require a decision making process for the type of 
channel to be used, these payments will still be forwarded to the flow 
control process before the payment is actually released to the channel. Step 
330 initiates the process of deciding if the specified channel is available. 

In step 335, it is determined whether or not the channel is 
available for use at all. In die preferred embodiment of the present 
mvention, a channel table is maintained which contains the status of all of 
the channels to which flie hub 120 is connected. An example of such a 
clearing channel table is in contained in Figure 10. If the channel is not 
available as determined by the status field contained in the clearing channel 
table, the process continues at step 365 described below. If the channel is 
available, it is then decided at step 340 whether or not the particular 
channel is on holiday. As some of the institutions which maintain the 
channels recognize national holidays which are not universal, a channel 
could be on a different holiday schedule than observed by the hub 120. 
The holiday schedule for each channel is maintamed m the clearing 
channel table (Fig. 10). If the channel is on holiday, the processing will 
continue in step 365. If the channel is not on holiday, it is determined 
whether or not the cut off time for the channel has been reached for the 
type of payment (for some channels different cut off times apply for MtlOO 
and Mt202 payments). The cut-off time is the last time of day at which a 
channel will except a payment for processing. The cut-off time details are 
contained in the channel table illustrated in Figure 10. If the cut-off time 
has already passed, processing continues in step 365, If there is sufficient 
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time to pass the payment on to the channel, the process continues in step 
350. Step 350 has been included in diis Figure to mdicate that additional 
checks may be made with respect to the chaimel availability such as the 
current debit position. 

If the channel availability tests 335-350 are all satisfied, it is 
determined in step 355 if there are any other special formatting 
requirements. The payment transaction is sent to flie flow control 
processing m step 360 (see step 255 in Fig. 5), 

If the processing has reached step 365, it is because flie 
requested or designated chaimel is not available for use. In step 365 it is 
determined whether or not the payment is a liquidity payment i.e., a 
payment initiated by the hub 120 solely for the purposes of moving funds 
firom one channel to another - moving the liquidity. 

If the payment is a liquidity payment, the channel can not be 
changed because of the nature of the payment as described above (step 
370). If such is the case, the payment is sent back to payment repair in step 
375 (see Fig. 5), 

If the payment whose chaonel is unavailable is not a liquidity 
payment (NO out of step 365) it is deteraiined whether or not there is any 
information contained in the payment transaction record which identifies 
the type of channel which should be used (e.g., use RTGS, but the specific 
RTGS channel is not identified). If such information does exist in the 
payment transaction record, the channel type is set to flie appropriate type 
(e.g., RTGS)(step 390). Note that /NETT/ is a generic coding used in the 
system to identify a request for a non RTGS clearing channel, while 
/RTGS/ identifies a request for an RTGS channel. If no such channel 
details exists in the transaction record, the channel type is set depending on 
the payment type of the instruction. The payment type will indicate the 
channel which was originally chosen. If this is of type RTGS, channel type 
will be set to /RTGS/. If it is of non RTGS type, channel type will be set to 
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/NETT/. The channel type is retrieved from the channel table contained in 
Figure 10. 

Once the channel type has been set, the payment type is set to 
CLG (step 395) and the payment transaction is sent on to Ae process for 
determining the particular channel as illustrated in Figure 7. 

Step 400 in Figure 7 is die initiation of the routing process 
when no specific route has been identified (step 327 in Fig. 6) or when die 
request for a specified channel could not be satisfied (step 397 in Fig. 6). 
In step 405 a list of available clearing channels is retrieved using die 
clearing channel tables depicted in Figures 9 and 10. If the transaction 
specifies that the payment should be processed through an RTGS or a non 
RTGS channel, any non-RTGS or RTGS clearing channels respectively 
should be excluded from this list 

In step 410 it is determined whether or not a destination 
clearing bank is direcdy connected to any of the same clearing systems as 
die hub 120. If clearing channel returned is TGT (TARGET) or COR 
(correspondent), there is no such mutual direct connection. 

If in step 4 10 it is determined that there is a mutual direct 
connection, in step 415 it is determined whether there is more than one. 
This determination is made using the clearing channel options determined 
in 405. The CMD table depicted in Figure 9 allows for the maintenance of 
channel membership by pay- bank. Each pay-bank/channel combination is 
held in a different record in the table. This structure allows for easier 
prioritizing of channels when a pay-bank is a member of more than one 
clearing system. The pay-bank/ channel information can either be 
manually maintained or an electronic batch process may capture the 
channel membership details. In order to limit die complexity of die router 
and otiier parts of the system, and to have a common interface to the pay- 
bank/channel details, it is preferred diat all channel member details are 
contained in a single table and each of the channel details confonn to the 
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same standard record format TTiis means for example that German 
clearing infonnation, which normally identifies banks with a local German 
BLZ code is not used. Instead, the universal Society for World-Wide Inter- 
bank Financial Telecommunications (SWIFT) code is used to identify 
banks. As illustrated in Figure 9, tiie CMD table also contains details 
relating to the preferred routing method. If a pay-bank and the hub 120 
have more Aan one mutual direct connection, the priority is indicated in 
the CMD table but only if this differs from the default priority as held on 
the ECC table illustrated in Figure 10. If the pay-bank and the hub 120 do 
not have a mutual direct connection, TGT (TARGET) and/or COR 
(correspondent) may be loaded on the ECC table with priority set where 
necessary. 

Returning to Figure 7, if the pay-bank is not a member of 
more than one clearing system (step 415) a validation is performed m order 
to verify that that channel can be used (step 420). As previously described 
with respect to steps 335-350 in Figure 6, such vaUdation can mclude 
determining if the channel is on holiday or if the cut-off time for Aat 
channel has been reached. Again, tins validation process employs the 
clearing channel table as depicted in Figure 10. If it is determined that the 
channel cannot be used (NO out of step 425) the proposed transaction is 
sent to repair for manual determination of how to process the transaction as 
previously described. If die channel can be used, the payment type ia the 
transaction record is set to the specified channel in step 435. 

Returning to the NO path out of step 410, this path is 

followed if either the TARGET system or a correspondent is to be used as 
the clearing channel. In step 440, it is detennined whether it is the 
TARGET system or a correspondent which is to be used. If a 
correspondent is to be used, the payment type is set to CPO and &e 
correspondent details are read from flie clearing channel table (Fig. 10). In 
step 445, the record for the correspondent in the clearing channel table is 
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read which contains the SWIFT addressed for the coirespondent which will 
enable routing of the paym^t transaction. 

In step 450, the process determines if diere are any specific 
formatting requirements for the channel which has been specified by the 
routing process, and the p^rment transaction is forwarded to the flow 
control process in step 455 (see Fig* 5). 

If it is determined in step 440 that the TARGET system is to 
be used, the list of available clearing channels obtained in step 405 is 
narrowed to only included the RTGS clearings. This narrowed list is &en 
prioritized according to default priorities. Similarly, in step 465, if a pay- 
bank is a member of more than one clearing system (YES out of step 4 15) 
the available clearing systems to which the pay-bank is a member are 
prioritized. However, in the instance the pay-bank override priority firom 
the CMD table (Figure 9) will be used if it is present In either of these 
cases, the list of available prioritized channels is passed to tbs process (Fig. 
8) for deciding the channel which is to be used to transfer the fimds in step 
470. 

Information on priority of payment channel is maintained 
manually. A default priority will be entered on the ECC table (Figure 10). 
If an override priority is to apply for a pay-bank this is entered on the CMD 
table (Figure 9). 

In step 500 of Figure 8, ±e prioritized list of channels which 
can be used to route the payment is provided to the channel decision 
process. In step 505, the priority will be changed if required by 
circumstances at the time the final decision is being made. For example, 
certain payment channels require a minimum volume of payments to be 
submitted as held on the ECC table (Figure 10). These "priority changes" 
are automated. 

In step 5 10, it is determined whether all of the channels in the 
list have been processed. If not, a decision making process is performed in 
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Steps 5 15-530. The decision making process 515-530 is the same as 
discussed above with respect to step 420 in Figure 7 and steps 335-350 in 
Figure 6. If a channel passes all the rules and can therefore be used, the 
payment type is set to the specified chaimel and any special formatting 
required for that channel is identified in step 535, The payment transaction 
is then sent to the flow control process in step 540. 

If all of the available channels have been processed and none 
of them, for one reason or another, is available for use (YES out of step 
5 10) an error is generated as no channel can be used (step 545), If such is 
the case, flie payment transaction is sent to repair for manual determination 
of the appropriate chaimel to use in routing the transaction (step 550). 

Supporting this invention there are a number of generic 
"housekeeping" processes which will run on periodic bases to ensure tiie 
smooth operatioa- These are not defined specifically, but include a nightly 
reset of Flow Control balances to zero and a cleardown of historical data 
firom the Flow Control Process. 

Although the present invention has been described in relation 
to particular embodiments thereof, many other variations and other uses 
will be apparent to those skilled in the art. It is preferred, therefore, that 
the present invention be limited not by the specific disclosure herein, but 
only by the gist and scope of the disclosure. 
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WHAT IS CLAIMED IS; 

1. A method of processing payment transactions by a 
financial institation having a plurality of branches, each payment 
transaction having a destination bank and each payment transaction being 
capable of being forwarded through a plurality of clearing systems, the 
mediod comprising the steps of: 

transmitting the payment transactions from the plurality of 
branches to a central location within die financial institution; 

determining, for each payment transaction, an impropriate 
clearing system which to forward the payment transaction; and 

forwarding each payment transaction to the determined 
appropriate clearing system. 

2. The method as recited in claim 1, fiirther comprising the 
step of designating a preferred clearing system for one of the payment 
transactions, and wherein the step of determining the appropriate clearing 
system considers the preferred clearing system. 

3. The method as recited in claim 2, fiirther comprising the 
step of determining if the preferred clearing system is available for use. 

4. The mediod as recited in claim 2, fiirther comprising the 
step of determining if the preferred clearing system is on holiday. 

5. The method as recited in claim 2, fiirther comprising the 
step of determining if a cutoff time for using the preferred clearing system 
has passed. 
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6. The method as recited in claim 1, wherein the plurality of 
clearing systems include Real Time Gross Settlement (RTGS) clearing 
systems, and Multi-Lateral Net Settlement (MLNS) clearing systems, and 
wherein the RTGS clearing systons can further use a Trans-European 
Automated Real-Time Gross settlement Express Transfer (TARGET) 
clearing system. 

7. The me&od as recited in claim 1, wherein the step of 
determining the appropriate clearing system further conq>rises flie step of 
determining if the step of forwarding the payment transaction would 
exceed a predetermined limit 

8. The method as recited in claim 7, wherein the 
predetermined limit is with set respect to the destination bank. 

9. The method as recited in claim 7, wherein the 
predetermined limit is set with respect to a proposed clearing system being 
considered for the appropriate clearing system. 

10. A metiliod of processing a payment transaction, the 
payment transaction having a destination bank and the payment transaction 
being capable of being forwarded through a plurality of clearing systems, 
the method comprising Hie steps of: 

(a) identifying candidate clearing systems which could be 
used to forward the payment transaction to the destination bank; 

(b) verifying that a first candidate clearing system is available 

for use; 

(c) verifying that a processing of the payment transaction 
does not exceed a predetermined value limit; and 
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(d) forwarding the payment transaction to the first candidate 
clearing system. 

1 1. The method as recited in claim 10, further comprising 

the steps of: 

sequentially repeating steps (b) and (c) for other candidate 
clearing systems until one of the other candidate clearing systems satisfies 
the verification steps of (b) and (c); and 

forwarding Ae payment transaction to the one other 
candidate clearing system. 

12. The method as recited in claim 1 1, further comprismg 
the step of manually routmg the payment transaction if none of the 
candidate clearing^ systems satisfy the verification of either steps (b) or (c). 

13. The method as recited in claim 10, further comprising 
the step of prioritizing the candidate clearing systems. 

14. The method as recited in claim 13, wherein tiie step of 
prioritizing further comprises the step of giving higher priority to a 
candidate clearing system identified by a customer as a preferred clearing 
system. 

15. The method as recited in claim 10, further comprising 
tiie step of determining if the destination bank is a member of more than 
one clearing system, 

16. The method as recited in claim 15, wherein the 
destination bank is a member of only the first candidate clearing system. 
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the method further comprising the step of manually routing the payment 
transaction if die verification of eidier steps (b) or (c) fail. 

17. The method as recited in claim 10, wherein the Trans- 
European Automated Real-Time Gross settlement Express Transfer 
(TARGET) is designated as a desired clearing system, the method further 
comprising the step of eliminating candidate clearing systems which are not 
Real Time Gross Settlement (RTGS) clearing systems. 

18. The method as recited in claim 10, wherein the 
verification of step (b) further comprises the step of detennining if the 
candidate clearing system is operational. 

19. The method as recited in claim 10, wherein the 
verification of step (b) further comprises die step of detennining if the 
candidate clearing system is on holiday. 

20. The method as recited in claim 10, wherein the 
verification of step (b) further comprises the step of determining if a cutoff 
tune for using the candidate clearing system has passed. 

21. The method as recited in claim 10, wherein the 
predetermined value limit is set with respect to die destination bank. 

22. The method as recited in claim 22, wherein die 
predetermined value limit is a limit of debits accepted by the destination 
bank. 
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23, The method as recited in claim 10, wherein the 
predetermined value limit is set with respect to the first candidate clearing 
system. 



24. The mediod as recited in claim 23, wherein the 
predetermined value limit is a limit of debits accepted by the first candidate 
clearing system. 

25. A metiiod of processing payment transactions by a 
financial institution having a plurality of branches, each payment 
transaction having a destination bank and each payment transaction being 
capable of being forwarded through a plurality of clearing systems, die 
method comprising the steps of: 

transmitting the payment transactions firom the plurality of 
branches to a central location wifliin die financial institution; 

for each payment transaction, determine an ^propriate 
clearing system which to forward the payment transaction by: 

(a) identifying, for each payment transaction, 

candidate clearing systems which could be used to 
forward the payment transaction to the destination 
bank, 

(b) verifying that a first candidate clearing system is available 

for use, and 

(c) verifying that a processing of the payment transaction 
does 

not exceed a predetermined value limit; and 
forwarding each payment transaction to the determined 
appropriate clearing system. 
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26. A system for processing payment transactions by a 
financial institution (100) the system comprising 

a plurality of branches (105-115) of the financial 
5 institution (100) r at least one branch generating payment 
transactions/ each payment transaction having a 
destination bank and each payxnent transaction being 
capable of being forwarded through a plurality of clearing 
systems; 

Q 10 a central location (120) within the financial 

^ institution (100)^ the at least one branch transmitting 

the payment transactions to the central location/ and 
W a payment router (170, 255) within the central 

5 location (120), the payment router (I70r 255) determining, 

m 15 each payment transaction^ an appropriate clearing 

system to which each payment transaction should be 
,fi forwarded, and the payment router forwarding each payment 

Q transaction to the determined appropriate clearing system, 

M. 27. Tne system as recited in claims 26/ wherein the 

tQ plurality of clearing systems include Real Time Gross 

Settlement (RTGS) clearing systems, and Multi-'lateral Net 
Settlement (MLNS) clearing systems, and wherein the RG6S 
clearing systems can fux-ther use a Trans-European 
Automated Real-Time Gross settlement Express Transfer 
25 (TARGET) clearing system. 

28. The system as recited in claim 26, further comprising 
a flow control module (170, 25S) coupled to the payment 
router (170,250), wherein the flow control module 
determines if the forwarding of the payment transaction by 
30 the payment router (170, 250) would exceed a predetermined 
limit < 
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29. The system as recited in elaims 29, wherein the 
predetermined limit is ser with respect to the destination 
bank. 

30. The system as recited in claim 29, wherein the 

5 predetermined value liinit is a limit of debits accepted by 
-the destination ban)c* 

31. The system as recited in claim 28, wherein the 
predetermined lixcuLt is set with raspect to a proposed 
clearing system. 

32. The system as recited in claim 31/ wherein the 
predetenained value limit is a limit of debits accepted by 
the proposed clearing system. 

gl 33. The system as recited in claim 26, wherein the 

^ payment router (170r 250} determines if the destination 

Tpi 15 bank is a member of more than one clearing system* 

6 

J 34- The system as recited in Claim 28, wherein rhe 

payment router (170, 250) identifies candidate clearing 
systems which could be used to forward the payment, 
transaction to the destination bank and wherein the 
20 payment router verifies that a first candidate clearing 
system is available for use- 

35. The system as recited in claim 34, wherein the 
payment router {170^ 250} determines if the candidate 
clearing system is on holiday, 

25 36, The system as recited in claim 34, wherein the 

payment router (1170, 250) determines if a cutoff time for 
using the candidate clearing system has passed^ 

37, The system as recited in claim 34, wherein if the 
first candidate clearing system is not available for use, 
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the payment router (170, 250) further verifying at least 
one of the other candiddte clearin? systetcis is available 
for use. 



38. The system as recited in cleim 37, wherein the 
5 payitLent router (170,250) manually routes the payment 

transaction if one of the candidate clearing systems are 
available for use. 

39. The system as recited in claim 34, wherein the 
paymant router (170r 250) prioritises the candidate 

10 clearing systems. 

40. The system as recited in claim 39/ wherein the 
payment router (170/ 250) gives higher priority to a 
candidate clearing system identified by a customer as a 
preferred clearing system. 
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